home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9608 / 000021_owner-urn-ietf _Sat Aug 17 01:36:59 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA24576 for urn-ietf-out; Sat, 17 Aug 1996 01:36:59 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA24571 for <urn-ietf@services.bunyip.com>; Sat, 17 Aug 1996 01:36:56 -0400
  3. Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA28884  (mail destined for urn-ietf@services.bunyip.com); Sat, 17 Aug 96 01:36:54 -0400
  5. Received: from void.ncsa.uiuc.edu (void.ncsa.uiuc.edu [141.142.103.20]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with SMTP id AAA14255; Sat, 17 Aug 1996 00:36:53 -0500
  6. Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
  7.     id AA14157; Sat, 17 Aug 96 00:33:18 CDT
  8. Date: Sat, 17 Aug 96 00:33:18 CDT
  9. From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
  10. Message-Id: <9608170533.AA14157@void.ncsa.uiuc.edu>
  11. To: Ron Daniel <rdaniel@acl.lanl.gov>
  12. Cc: urn-ietf@bunyip.com
  13. Subject: [URN] Iterative lookup
  14. In-Reply-To: <2.2.32.19960816220043.006d34f4@acl.lanl.gov>
  15. References: <2.2.32.19960816220043.006d34f4@acl.lanl.gov>
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. Thanks for the example, Ron.  That makes it abundantly clear.
  22.  
  23. Ron Daniel writes:
  24.  > So, that is one way it could be done. I am not wild about the
  25.  > number of lookups that are needed, but I like it better than
  26.  > adding a non-standard flag to regexps.
  27.  
  28. Most of the info will be cached locally if you are resolving a URN
  29. that is similar to previous URNs.  This is proportional to the
  30. computational complexity and network/server load of gethostbyname for
  31. every single DNS lookup.  So this should not be considered an argument
  32. against iteration.  Yes, servers and DNS requests are optimized for
  33. gethostbyname lookups, but I think the difference is relatively
  34. minor.
  35.  
  36.  > I think it is pretty rare that we will have a namespace that
  37.  > has such a mapping to DNS.
  38.  
  39. The path scheme requires exactly this kind of iteration and reversal
  40. of names to get DNS names. 
  41.  
  42.  > [...]  I think most namespaces
  43.  > will very quickly point the user to a database that handles
  44.  > very large chunks of the namespace.
  45.  
  46. Depends on what you mean by this.  If you mean that after the NAPTR
  47. resolution algorithm is done, the opaque string is handled
  48. internally to a server, then I think this is the wrong approach
  49. because it is unscalable for really large name spaces and large
  50. numbers of users.  The basic problem is that there is no way for
  51. clients to know about a subdivision of the name space, should
  52. subdivision become necessary in the future, without asking the server
  53. for every single name.  What the client needs is a rule it can cache
  54. and use later to subdivide the space when resolving another name.
  55. This means that the previously opaque string is no longer opaque
  56. because clients must be responsible for resolving it using the rule.
  57.  
  58. It's OK with me that some name spaces work this way, but we should
  59. not require it of all name spaces.  
  60.  
  61. dan